Disk Forensics > [T1]: Windows Event Logs: structure & Analysis

Now that we have discussed how to acquire digital evidence, it's time to explain the internal mechanics of Windows and Linux operating systems. Being familiar with important artifacts and the type of information we can get from each one is a mandatory skill for forensic analysis. It will help you perform investigations in less time with more efficiency.

For Windows operating systems, you will utilize two key components almost in every investigation; event logs and registry. Let's start with event logs.


Windows event logs are special files that record all happening events on a Windows computer, broken down into three primary categories: 

  • System logs: events logged by the operating system, like system startup/shutdown and services started/stopped.
  • Application logs: events logged by third-party applications installed on Windows, such as Outlook.
  • Security logs: events relevant to the system's security, such as account successful/failed login attempts, file deletion, process tracking, and account management (e.g., users added/removed from the 'administrators' group and password resets).

One important thing to note is determining the granularity of the logging level you want, which is something you can configure and control using group policies, in particular, audit policy. As a forensic analyst, there is nothing worse than facing a situation where you cannot solve an investigation just because one specific log type was not enabled. For example, without 'successful login' logs, you will not be able to determine the systems the attackers logged into using a compromised account).

Ideally, a 'log everything' approach is great. More logs mean more information...right? Unfortunately, we cannot log everything. The more logs you have, the bigger disk space you need to store them, the greater the network bandwidth you need to ship them to your SIEM, and finally, the more performance power you need to process and parse them. That's why you should have a good understanding of available resources in your environment, prioritize what to log based on importance, and finally balance security and operations. A typical security engineering exercise. The better you prepare your logging in advance, the smoother your investigations will be.


By default, Windows Event Logs are stored at 'C:\Windows\system32\winevt\logs' as .evtx files. The default location can be changed in Windows registry under 'HKLM\SYSTEM\CurrentControlSet\Services\EventLog\'.

 

Windows Event Log Files

These EVTX files are stored in binary format and require special programs to view their content. Windows has a built-in application called Windows Event Viewer, which scans those log files, aggregates them, and present them in a friendly and easy-to-navigate interface. The easiest way to access the event viewer is to open Command Prompt CMD, type 'eventvwr', and press Enter.

 

Windows Event Viewer

In addition to the built-in event viewer, there are third-party tools such as "Event log explorer" and "Full Event Log view" that offer more features (e.g., enhanced filtering and sorting). Note that event logs will be shipped to your SIEM in a professional environment. However, viewing logs on the subject system may be the only option when investigating a standalone system that has not been configured for log forwarding.

 

Event Log Explorer

 

Generally speaking, event logs can have any of the following types (indicated in the first column):

 

Event Log Types

  1. Error: An event that indicates a significant problem, such as data or functionality loss. For example, an Error event is logged if a service fails to load during startup.
  2. Warning: An event that is not necessarily significant, however, may indicate the possible occurrence of a future problem. For example, a Warning message is logged when disk space starts to run low.
  3. Information: An event that describes the successful operation of a task, such as an application, driver, or service. For example, an Information event is logged when a network driver loads successfully.
  4. Success Audit: An event that describes the successful completion of an audited security event. For example, a Success Audit event is logged when a user logs on to the computer.
  5. Failure Audit: An event that records a failed security access attempt. For example, if a user tries to log in and fails (i.e., incorrect password), the attempt is logged as a Failure Audit event.

Log types of 'error,' 'warning,' and 'information' are common in the 'system' and 'application' categories. On the other hand, the 'security' category will have either 'success' or 'failure' audit types. To see log details, double-click the subject log. Event logs are constructed to answer the What, When, Where, Who, and How questions you may encounter during investigations:

 

Detailed view of an event log

 

  • What and how:
    • Category: showing event type (e.g., log on, log off...etc.).
    • Event ID: indicating event sub-type. Every event is assigned a unique number to make it easier to search and filter. For example, login success Event ID is 4624, and login failure is 4625. Feel free to check this resource for a comprehensive list of Event IDs.
  • When: Logged timestamp indicating event date and time 
  • Where: Computer field showing involved system.
  • Who: Account Name of the involved user.
← Prev Dashboard Next →